@llvm/pr-subscribers-lldb

Author: Ebuka Ezike (da-viper)

diff --git a/lldb/source/Interpreter/CommandInterpreter.cpp b/lldb/source/Interpreter/CommandInterpreter.cpp
index 112d2f20fda41..a4071f5f0a602 100644
--- a/lldb/source/Interpreter/CommandInterpreter.cpp
+++ b/lldb/source/Interpreter/CommandInterpreter.cpp
@@ -444,6 +444,7 @@ void CommandInterpreter::Initialize() {
   if (cmd_obj_sp) {
     // Ensure `e` runs `expression`.
     AddAlias("e", cmd_obj_sp);
+    AddAlias("expr", cmd_obj_sp);
     AddAlias("call", cmd_obj_sp, "--")->SetHelpLong("");
     CommandAlias *parray_alias =
         AddAlias("parray", cmd_obj_sp, "--element-count %1 --");
@@ -1376,7 +1377,9 @@ bool CommandInterpreter::GetAliasFullName(llvm::StringRef cmd,
 }
 
 bool CommandInterpreter::AliasExists(llvm::StringRef cmd) const {
-  return m_alias_dict.find(cmd) != m_alias_dict.end();
+  std::string alias_name;
+  return GetAliasFullName(cmd, alias_name);
+  // return m_alias_dict.find(cmd) != m_alias_dict.end();
 }
 
 bool CommandInterpreter::UserCommandExists(llvm::StringRef cmd) const {

The lldb command line was designed so that it always does shortest complete match, and there are a lot of common commands that people only type partially. Adding one more expr alias isn't such a big deal, but adding special purpose aliases for all the shortenings people want to use is not supportable (and might collide with other aliases users have set).
So we need a better solution to this DAP problem than just adding aliases.

Another solution I could think of is prioritising, the repl command type instead of the repl variable type.
in

or add the previously defined aliases in docs explicitly as aliases.

So we need a better solution to this DAP problem than just adding aliases.
How about for aliases that are mentioned in the documentation, we explicitly set those as aliases.

We may use the word expr in documentation, but that doesn't mean that a user could decide they wanted to use expr for something completely different. And even if we added an explicit alias for expr someone who was using it for another purpose will just get a little annoyed, then do:

command unalias expr
command alias expr <whatever it was before>

So it doesn't seem wise for DAP to depend on the fixed meaning of aliases.

@da-viper , I'm a bit surprised by this. Which mode are you using for the debug console?
I remember that in Variable mode (or whichever is the default), I was able to type :expr <something> and that worked.

Is your problem occurring in the Auto mode? I think that in this case, using a prefix like : should be enough to disambiguate. What do you think?

Adding aliases is error prone because there may be people who use expre instead of expr and then this logic breaks.

I am using what is the default. which is automode.

I am not sure if there is a way to change the mode from the user.

Probably the default is Auto. I guess we should add an option in the typescript code for selecting the mode.

And about :, I confused you because I set up my debugger to use : instead of a backtick.

In this mode, I think it would be great to determine via a quick parsing if the input string is an actual expression or not. What would be nice would be do this:

• If the input string consists of at least two words, then run some quick command parsing to see if it's valid or not. If it's valid, then execute it as a command, otherwise follow the existing code path

what do you think?